The present invention relates to a service on IP (Internet Protocol), in particular to IP telephony called “Voice over IP”.
IP telephony advantageously allows, on the one hand, a reduction of the cost of telephonic communications in comparison with conventional telephony and, on the other hand, the coupling of telephony with the functions and services of data processing and of IP networks.
A telephony service is a real time service which requires a relatively high level of availability and robustness. In the context of conventional telephony (STN for ‘Switched Telephone Network’), based on circuit switching, this level of robustness and availability is obtained by the use of methods which are not applicable to IP telephony, which is not based on circuit switching.
An IP network providing a telephony service conventionally comprises a service platform, as well as equipment for accessing the service, or POPs (Points Of Presence), which are in charge of managing the access of user client terminals to the service in question.
In standard fashion, these POPs are associated with Border Session Controller (BSC) equipment (also known as Session Border Controller (SBC) equipment), whose principal functions have been identified in the document ‘Requirements from Session Initiation Protocol Session Border Control Deployments’, by J. Hautakorpi et al., draft-ietf-sipping-sbc-funcs-00.txt, November 2006. These SBCs are situated between the client terminals and the platforms of the IP telephony service. An SBC is in general situated in a POP for access to the IP network (without this however being a necessary condition for the functioning of the telephony service) and represents, for a given client terminal, a unique point of entry to the telephony service. Such management of access to a service makes it possible to mask the service platform and, more generally, the network architecture used by an operator, from the client terminals. It is then possible to guarantee service impregnability.
SBCs correspond to a point of passage both for the signalling flows, aimed at establishing a communication, and for the media flows which pass between the client terminals. Signalling flows can encompass the establishment of a communication, for example based on protocols such as SIP (Session Initiation Protocol), or also H.323, as defined by the ITU-T (International Telecommunication Union Telecommunication Standardization Section), or also IAX (Inter-Asterisk eXchange Version 2) as defined in the document draft-guy-iax-02, Work In Progress, October 2006 by Spencer, Shumard, Capouch and Guy. As for the media flows, these can be exchanged between client terminals according to protocols of the RTP (Real-Time Transport Protocol) type, or even the IAX type.
An SBC therefore receives, on the one hand, signalling messages from the service platform, or from the client terminals respectively. Then, after processing these messages, the SBC relays them to the client terminals, or respectively to the service platform.
Then, when a media flow is exchanged from a first client terminal to a second client terminal of the service, which are associated with a first and a second SBC respectively, this media flow is received at the first SBC, then relayed to the second SBC, the latter then being in charge of transmitting this media flow to the second client terminal. By proceeding thus, the client terminals cannot communicate directly with each other, the impregnability of service thus being guaranteed.
It can also be noted that the SBCs can also provide other functions such as a filtering function or an address translation function for services based on the IPv4 protocol.
Thus by virtue of their role in an IP telephony network, SBCs appear to be potential concentration nodes for failures that can lead to a breakdown in the service provided to clients whose terminals would be managed by an affected SBC.
In order to increase the failure resistance in such a network and robustly and efficiently convey the signalling messages making it possible for communications to be established, as well as conveying the media flows between the client terminals, backup SBCs are provided conventionally, so that it is possible to substitute a backup SBC for a defective SBC. Such an architecture requires the backup SBC to have a configuration and behaviour identical to the SBC which it replaces, both in terms of client terminals and service platform.
The term ‘network’ is understood to refer not only to the network layer, i.e. layer 3, of the OSI (Open System Interconnection) model, but also to any interconnection between different items of equipment.
However, providing such backup equipment has many drawbacks.
Firstly, SBC duplication within a POP is costly, particularly since SBCs are increasingly in charge of different functionalities. This solution also represents an additional service cost, requiring in particular a separate electrical supply and technical rooms with a larger surface area.
Furthermore, failure detection and the management of a switchover from a defective SBC equipment to a backup SBC conventionally rely on proprietary mechanisms from the manufacturer of this equipment which as a result are generally not mutually compatible.
Moreover, the larger the number of SBCs attached to a service platform, the higher the maintenance cost, as well as the cost associated with maintaining the synchronization between the possibly defective SBC on the one hand, and the backup SBC or SBCs on the other hand.